COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	∂28-Feb-83  2201	sandy@Whitney 	grinnell, 11   
C00027 ENDMK
C⊗;
∂28-Feb-83  2201	sandy@Whitney 	grinnell, 11   
Received: from SU-WHITNEY by SU-AI with PUP; 28-Feb-83 22:01 PST
Date: 28 February 1983   22:01:07-PST (Monday)
From: sandy@Whitney
Subject: grinnell, 11
To: aam at sail

Hi Allan.
	I was wondering if you could help me out a little with the pdp 11
/grinnell stuff. Mainly with power-cycling the 11 and fishing the dr11b out.
I don't have any experience doing this with any computers that are bigger than
a bread box, and all they cared about was having their floppies not in.
	Also, do you know if it is going to matter that we are planning to 
install the dr11b in a slot where there is currently a DEC dr11w? I'm guessing
that the backplane won't care, but I don't know for sure. I called MDB and
they say that the board should work fine in a vax unibus. 
	Am I correct to assume that the 10 doesn't need to be powered down
(heaven forbid)?
	I got the cable and connectors and stuff,  but am holding off pressing
the connectors until I see how much cable we really need. I also got a wrap
card to use as a slot filler and daisy chain passer thougher for the 11.
	If you could show me how to do this stuff once, I think I could 
cope with it from then on.
	Would Wednesday afternoon be ok? I'm tentatively planning a test for
Wednesday night if the parties using the involved equipments are amenable.
Jeff Mogul is willing to boot the new version of the system with the grinnell
driver then.
					-Sandy

I don't know how much I can help, but how about 4PM Wednesday.  I think that
you had better try to get Ron Goldman to be there also, and send a note to
AL.DIS[DIS,TOB] on SAIL mentioning the PDP11 shutdown.
					Allan
∂10-Mar-83  1331	TOB  	grinnell | Ethernet
Allan
Please describe your design to me for the SAIL
end.
Tom

I'm not sure exactly what you mean.  I assume you mean:  what changes will
have to be made to run SAIL's Grinnell software if the Grinnell is connected
to the VAX?

The first thing is that an FTP-style program will have to be written for
the VAX to listen to the ethernet for connections of the right kind and
transfer data to and from the Grinnell.  Then, the SAIL software will
have to be modified so that the routine which currently puts data into
the Hand-Eye PDP-11's memory instead puts the data into an ethernet packet
and sends it to the VAX.  Next the routine which reads data out of the
PDP-11's memory will be modified to receive data from an ethernet packet.
Finally, there are a few special-purpose routines which directly write
into or read from the PDP-11 without using the standard routines mentioned
above; these will have to be located and modified.
					Allan
PS. The software development should be done with a dummy program running
on the VAX, and the resulting configuration tested to see what kind
of delays can be expected by using the ethernet for data transmission.
eyal@whitney
EM@SAIL

PUPFTP[NET,TVR]

∂07-Apr-83  0024	sandy@Whitney  
Received: from SU-WHITNEY by SU-AI with PUP; 07-Apr-83 00:23 PST
Date: 7 April 1983   00:26:37-PST (Thursday)
From: sandy@Whitney
To: aam at sail

allan-
	are you still interested (willing?) to do the revs to the grinnell
sail code for the net?
	we have what appears to be a genuine unix hacker helping us (with
experience and everything) in the person of eyal mozes. if you are still
willing, it would probably be appropriate to get together and discuss 
strategey, could you suggest a time?
	it appears that bsp protocol is the way to go.. at least at the
vax end. 
					-sandy

∂14-Apr-83  0059	sandy@Whitney  
Received: from SU-WHITNEY by SU-AI with PUP; 14-Apr-83 00:59 PST
Date: 14 April 1983   01:00:02-PST (Thursday)
From: sandy@Whitney
To: aam at sail

allan-
	i here that you are very busy now. perhaps if you are willing to 
do the grinnell /en hacking in the future we can start the other end before.
	i spoke to ME and he said that the tcp (dod standard) won't be 
available at the user level for ethernet on sail until september or later.
given this bsp (pup protocol, byte sychronous ) seems to be the appropriate
layer to use. 
	bsp is used to implement telnet and ftp.
	bill nowicki had an interesting idea, which is to use telnet. telnet
uses bsp, and takes care of a lot of the grunty details. basically, the
sail grinnell driver would telnet whitney and log on and start the server
program there. then instructions written to the grinnell would be split
up into bytes and sent (like characters). telnet escape characters would 
have to be escaped. 
	i've looked at the telnet code on whitney , and it doesn't look like
it would slow bsp down terribly (perhaps we should estimate how much). 
	similarly, grinnell readback data would be read from the return byte 
stream. 
	when things were finished, the grinnell handler on sail would log
its job off of whitney using some very obscure sequence and a k <cr>.
	another detail is that after starting the server the sail code would
wait for a confirmation message that meant that the grinnell opened 
alright at whitney.
	come to think of it there should probably be a feature whereby
whitney can complain back that the grinnell isn't working. another 
unlikley sequence?
	
	what do you think?
					sandy










allan-
	are you still interested (willing?) to do the revs to the grinnell
sail code for the net?
	we have what appears to be a genuine unix hacker helping us (with
experience and everything) in the person of eyal mozes. if you are still
willing, it would probably be appropriate to get together and discuss 
strategey, could you suggest a time?
	it appears that bsp protocol is the way to go.. at least at the
vax end. 
					-sandy

∂14-Apr-83  0246	AAA  
 ∂14-Apr-83  0132	HHB  	ether, etc.   
Allan,

We (or rather, they) who are looking into SAIl-VAX-Grinnell graphics
need some of your advice.. can I (plus/or) they get together with you
sometime soon to figure out a few things?  It's been suggsted that
one easy way might be to have the device driver on SAIL log in an
FTP job, and then just FTP stuff to whitney.. for example..

I know you're busy..

Harlyn

∂19-Apr-83  1037	mogul@Shasta 	Re: PUP, cont'd.     
Received: from SU-SHASTA by SU-AI with PUP; 19-Apr-83 10:37 PST
Date: Tuesday, 19 Apr 1983 10:40-PST
To: Allan Miller <AAM at SU-AI>
Subject: Re: PUP, cont'd.  
In-reply-to: Your message of 19 Apr 83  0121 PST.
From: Jeff Mogul <mogul@Shasta>

A lookup of the string "grinell-server" will now return a proper
response.  The format of the response packet (if the name is found)
is from 1 to n "ports", where a port is a packed data structure
containing one byte each for net # and host # (or maybe in the
other order, depending on what kind of machine you're on) and a
4-byte socket number.  There are multiple ports if the host has
multiple addresses (e.g., a gateway.)

On the Vaxen, there's a library routine that makes this quite easy;
do "man 9 mlookup".  (This also works on Suns.)

-Jeff

Thanks for adding the name server entry.  However, there's two small
problems.  First of all, the name should be spelled "grinnell-server", not
"grinell-server".  You can leave the old entry in, but if it's not TOO
much trouble I'd kind of like to see the preferred spelling also.  Second,
it appears like the request for "grinell-server" returns the bytes (octal)
0, 0, 0, 0, 0, 104.  Should the network and host number be zero like this?
It seems like they should be the network and host for "whitney", although
if the standard protocol is to make a separate name server request for
"whitney" I'm perfectly willing to do that.
					Allan
∂20-Apr-83  1119	mogul@Shasta 	griNNell   
Received: from SU-SHASTA by SU-AI with PUP; 20-Apr-83 11:18 PST
Date: 20 April 1983   11:10:31-PST (Wednesday)
From: mogul@Shasta
Subject: griNNell
To: aam at su-ai

I've changed the name to Grinnell-Server.  This name denotes a socket,
but not a host; if you want a specific host+socket, you can ask the
nameserver for "Whitney+Grinnell-Server" -- all of the proper nameservers
should be able to handle this.

Although there may never be another Grinnell at Stanford, this allows you
to use the socket name on several hosts.

-Jeff

∂20-Apr-83  1421	eyal@Whitney   
Received: from SU-WHITNEY by SU-AI with PUP; 20-Apr-83 14:21 PST
Date: 20 April 1983   14:09:52-PST (Wednesday)
From: eyal@Whitney
To: aam at sail, allan

A. It seems to me that the mlookup function is intended to be used by
the initiator for looking up where to find the passive side, so it's
not really suited for what I need. Looks like the best thing is just to
ask mogul what socket he gave us and then use it.


B. I did test my program, and it now works. It waits until someone
opens a connection, can then both recieve and transmit information (in
16-bit-word units), and returns to waiting when the connection is
closed by the other side.


∂21-Apr-83  1304	eyal@Whitney   
Received: from SU-WHITNEY by SU-AI with PUP; 21-Apr-83 13:04 PST
Date: 21 April 1983   13:07:57-PST (Thursday)
From: eyal@Whitney
To: aam at sail, allan

A. Sorry, my mistake. Anyway, now is much too early to deal with that.

B. Yes, I did the testing by having whitney talk to itself. Notify me
as soon as your side is finished, and then we can test them together.

∂10-May-83  0940	JJW  	Buffer byte counts 
I saw your message to ME about getting the right byte count in buffers.  While
the standard "interface" between device servers and UUOCON in the system allows
only a word count to be passed, the TOPS-10 people adopted a much better kludge
than ours for figuring out padding bytes.  This allows a correct byte count to
be passed to the user program in the buffer header, so you don't have to worry
about checking 1's in the low-order bits of a word.

We've added something similar to WAITS; so with TCP, buffers from the IMP get
the byte count computed correctly.  Unfortunately PUPSER doesn't do this yet as
far as I know, but it wouldn't be very hard to fix it.

∂10-May-83  1052	ME  	device byte counts  
To:   AAM
CC:   JJW   
 ∂10-May-83  0330	AAM  	Input/output  
A buffer header's third word is supposed to be the "byte count".  However,
I tried an experiment and it seems to be some even multiple of the word
count.  For example, a disk file with just "AB" in it seems to return a
byte count of 5 when reading it.  Does this mean that there is no way to
distinguish between end-of-file (actually end-of-buffer) and zero data at
the end?

The reason I am asking is because PUPSER has a rather baroque way of indicating
the true end of the buffer, and I was wondering if it was really necessary
[it would be if the "standard" way of doing I/O left the byte count always
equal to some multiple of the number of bytes/word].
					Allan

AAM - well, never mind.  I just read p. 207 in the UUO manual, and the "baroque"
way is the same way that is used for the IMP.  So I guess I'm stuck with it.

ME - Well, actually, Joe recently wrote some new code for the IMP that allows
it to specify a non-whole-word byte count (which indeed didn't used to be
possible).  Probably we'll extend that technique to device PUP.  The current
baroque technique for PUP is useable but definitely ugly.  Of course, some
devices (like the disk) always store/retrieve whole words anyway.

∂10-May-83  1250	eyal@Whitney 	test  
Received: from SU-WHITNEY by SU-AI with PUP; 10-May-83 12:50 PDT
Date: 10 May 1983   12:54:03-PDT (Tuesday)
From: eyal@Whitney
Subject: test
To: aam at sail, allan

I'm here most of the time. It's you who's never around during regular
hours.

If you can be here on thursday, preferably late afternoon, or on friday
afternoon, notify me and we can do the test then.

If you'd rather do it by yourself, my program is /supp/eyal/connect. It
runs continouosly, and prints on the terminal any message it recieves.
It also transmits anything typed on the terminal. The only way to stop
it is by <ctrl>\ , or by kill from another terminal.

If you do the test by yourself, please send me mail about the results.

--------
Depends on what you mean by "regular hours".

I can't see anything in connect.c that opens a connection to SAIL.  Therefore,
as expected, connect.c receives the message that SAIL sends, but doesn't seem
to send to the SAIL receiver.  However, since I've only debugged the receiver
by sending to it from SAIL, it could very well be my fault.

Also, since /supp/eyal/connect uses the same socket to send and receive, I
really don't understand why it doesn't receive its own messages!  When I
opened and closed connections to it, it occasionally said "read error from
device", so it may be getting confused.

I think Thursday afternoon will be fine.  I will check and make sure.

PS. Where did you find documentation on BSP on whitney?  If I have time I
will try to look at /supp/eyal/connect.c more closely.

If you would like to try the SAIL side, say  ALIAS PUP,AAM  and then say
EX PUPSND  to send from SAIL to whitney  or  EX PUPRCV  to receive from
any host (I think).   Feel free to experiment, but please save a copy of
the existing programs before changing them.

					Allan
∂12-May-83  1626	AAM  
Need to send some kind of closing mark to close connection.
/supp/eyal/close.c

definitions:
/usr/include/pupconstants.h

∂12-May-83  1644	AAM  	more pup 
newline → line feed

∂12-May-83  1658	AAM  
Packet size=1024 or less for now   code 1=write, 2=read (1st 2 bytes)
in read code, next 2 bytes is length (if greater than packet size, data will come
back in multiple packets)  length is unsigned integer.

in write code, there is no length (entire packet is written)


closing connection

∂16-May-83  1325	eyal@Whitney 	our program
Received: from SU-WHITNEY by SU-AI with PUP; 16-May-83 13:25 PDT
Date: 16 May 1983   13:28:53-PDT (Monday)
From: eyal@Whitney
Subject: our program
To: aam at sail

One mistake I made: bsp doesn't work for 1024-byte-sized packets. The
maximum size is 512 bytes (though it may be possible to change it if
absolutely necessary).

∂06-Jul-83  1330	ME  	device PUP
 ∂05-Jul-83  2322	AAM  	PUPSER[S,SYS]/28P/59L   
Looking at this, does PUPSER take the byte count from the buffer itself or
does it compute it from the byte pointer in the buffer header?  Also, presumably
it looks at the low-order bits in the last word to get the exact byte count.
I was just wondering if the IOWC bit in the device status is used (presumably
it would have something to do with the routine ITMCNT, which I couldn't find).
					Allan

ME - PUPSER has recently been changed, along with IMPSER, to use the actual
byte pointer to compute the exact byte count.  The low-order bits are no
longer used, so you don't have to worry about that problem any more, if you
use the byte pointer in the usual way, with ILDBs and IDPBs.

The IOWC bit implies that the user program has counted output words (not
bytes) and stuck the count in the third word of the buffer (for each
buffer).  I don't recommend that at all; it is useful mainly if you are
BLTing the data from one device's buffer to another's.

7/8
Earlier we had a little problem with closing the connection.  Just to clear
things up, here is what SAIL does when it closes the connection:  It sends
a packet of type RTP-END, waits for a packet of type RTP-ENDR, and then
sends a packet of type RTP-ENDR.  I'm not sure exactly what you have to
do on the Whitney end to deal with all of that, but good luck.
					Allan